home *** CD-ROM | disk | FTP | other *** search
-
- C64 PICTURE FORMATS
- ===================
-
- By Matt Francis (m.p.francis@newcastle.ac.uk)
-
-
- INTRODUCTION
- ------------
-
- Several people have asked me to include information on the different picture
- formats with this release of ShowVIC. Well, information wants to be free,
- so here are details of all the formats ShowVIC supports. The following
- labels are used:
-
- Load - Load address (first two bytes of the file)
- Length - File length in bytes (including load address bytes)
- Bitmap - Bitmap offset (8000 bytes)
- Screen - Screen data offset (1000 bytes)
- Colour - Colour data offset (1000 bytes)
- ScrCol - Screen colour offset (1 byte)
-
- The offsets given for the bitmap, screen data etc. do not include the two
- load address bytes.
-
- NOTE: If you don't know anything about how the C64 stores bitmaps, you will
- find it very hard to write a conversion program. If this is the case, I
- recommend you read about bitmaps in a good C64 reference book before
- attempting to write a conversion routine.
-
-
- THE FORMATS
- -----------
-
- Art Studio (hires): Load - $2000
- Length - 9009
- Bitmap - 0
- Screen - 8000
-
-
- Image System (hires): Load - $4000
- Length - 9194
- Bitmap - 0
- Screen - 8192
-
-
- Blazing Paddles (multicolour): Load - $A000
- Length - 10242
- Bitmap - 0
- Screen - 8192
- Colour - 9216
- ScrCol - 8064
-
-
- Koala (multicolour): Load - $6000
- Length - 10003
- Bitmap - 0
- Screen - 8000
- Colour - 9000
- ScrCol - 10000
-
-
- Advanced Art Studio (multicolour): Load - $2000
- Length - 10018
- Bitmap - 0
- Screen - 8000
- Colour - 9016
- ScrCol - 9001
-
-
- Artist 64 (multicolour): Load - $4000
- Length - 10242
- Bitmap - 0
- Screen - 8192
- Colour - 9216
- ScrCol - 10239
-
-
- Vidcom 64 (multicolour): Load - $5800
- Length - 10050
- Bitmap - 2048
- Screen - 1024
- Colour - 0
- ScrCol - 2024 (see note at end)
-
-
- Image System (multicolour): Load - $3C00
- Length - 10218
- Bitmap - 1024
- Screen - 9216
- Colour - 0
- ScrCol - 9215
-
-
- Doodle (hires): Load - $5C00
- Length - 9218
- Bitmap - 1024
- Screen - 0
-
-
- FLI (see notes at end): Load - $3B00
- Length - 17474 or 17666
- Bitmap - 9472
- Screen - 1280 (8000 bytes)
- Colour - 256
- ScrCol - 0 (200 bytes)
-
- Hi-Eddi: Load - $2000
- Length - 9218
- Bitmap - 0
- Screen - 8192
-
- Amica-Paint: Compressed Koala pictures
-
-
- SPECIAL NOTES ON VIDCOM
- -----------------------
-
- Unfortunately, Vidcom doesn't seem to store the screen colour in its bitmap
- files. To get round this, ShowVIC takes the screen colour from offset 2024
- ($7E8), which is usually a zero (so Vidcom pictures will normally be
- converted with a black background, even though Vidcom itself uses dark blue
- by default). This can be changed by loading the picture into a binary file
- editor like NewZap or DekSid, and changing byte 2026 (2024+2 for load
- address bytes) to a value from 0 to 15. Of course, you could do this on a
- C64 before actually transferring the picture. The best solution is to avoid
- using the Vidcom format - Koala or Advanced Art Studio is preferable.
-
- One more thing about Vidcom: it seems to use exactly the same format for
- both hires and multicolour pictures, making it impossible to distinguish
- between them. For this reason, ShowVIC currently assumes all Vidcom
- pictures are multicolour. If many people badger me (can't see it
- happening), I might add a switch in a later release, so you can choose which
- mode to convert to.
-
-
-
- SPECIAL NOTES ON FLI
- --------------------
-
- For a full description of FLI, I refer you to Pasi Ojala's article in issue
- 4 of the "C= Hacking" magazine. Here are a few notes on implementing the
- format.
-
- The only difference between converting this format and converting a normal
- multicolour bitmap is that (a) the screen colour ($D021) changes every
- scanline, and (b) every byte of every character block in the bitmap has its
- own byte of screen data. The screen data is organised in 8 pages of 1000
- bytes each. When an FLI picture is displayed on a C64, the screen RAM page
- is changed every scanline, so the first pixel line of bytes (*not* the first
- 40 bytes) in the bitmap uses the first 40 bytes from the first page of
- screen data. The second pixel line uses the first 40 bytes from the second
- page of screen data, and so on. Hopefully this example will help clarify
- things:
-
-
- Byte in Char. Screen Screen
- bitmap block data page data byte
- -------------------------------------------------
- 0 0 0 0
- 1 0 1 0
- ... ... ... ...
- 7 0 7 0
- 8 1 0 1
- 9 1 1 1
- ... ... ... ...
- 15 1 7 1
- 16 2 0 2
- ... ... ... ...
-